Establish Infrastructure #105
Conversation
|
Amazing! On the file structure, since this repo is also meant to store files related to the project, can I suggest that we create a |
|
I was also wondering if you could break down the PR a bit more. I think there are changes here that are ready to be merged independently |
It seems feasible by writing a filter to the josh, though I haven't tried it yet. IMO it's OK to keep our
Yea makes sense. I'll split it up. |
|
CI wants some rustfmting |
| env: | ||
| TOOLS_BIN: "/tmp/smir/bin" | ||
| # Note that the downloaded version is dated 2025-08-09. | ||
| toolchain: nightly-2025-08-10 |
There was a problem hiding this comment.
I would prefer a toolchain toml file, as we'll update it frequently and that's easier to automate than editing a github workflow
Fine for now tho if you want to land this first and tune later
There was a problem hiding this comment.
Ah makes sense. I'd like to update it later together with the automation pr
|
This changes the rustc_public crate. Can you check that it still works inside the rust repo if synced back? |
|
The rustc compilation fails directly since we have a really strict msrv in our build.rs. Can we use the |
|
wait, is it possible to keep the files for the crates.io version in a separate directory? We can specify which Cargo.toml to use when building, and Cargo.toml itself can define the lib and build files. |
Yea. I think the plan was to overwrite the sources of the crates.io copy every time we make a breaking change? |
|
Yes the rustc version would be the base of a new major release |
buildis implemented here. This PR implements./x build,./x test [--bless],./x fmt [--check],./x githook install/uninstalland./x clean. Windows is not supported yet.compiletestcrate into a single file, making it possilbe to run test suites usingcargo test.